Description

This PR implements TAT-1729, adding expected profit/loss calculation display to the Auto Close (TP/SL) configuration screen. It also includes several UX improvements based on design refinements.

What is the reason for the change?

Users need to see the expected net profit or loss when setting TP/SL values, accounting for trading fees. This helps them make informed decisions about their risk management strategy. Additionally, several UX improvements were needed to match the final design specifications.

What is the improvement/solution?

1. Expected P&L Display: Shows real-time expected profit/loss below TP and SL input fields

   • Calculates net P&L by deducting MetaMask and protocol fees from gross profit/loss
   • Dynamically displays "Expected profit: $X.XX" or "Expected loss: $X.XX" based on the net value
   • Handles edge cases where TP creates loss or SL creates profit (for modified positions)
   • Right-aligned text in BodyMD font with Alternative color
   • Formats values using existing formatPerpsFiat with PRICE_RANGES_MINIMAL_VIEW

2. Terminology Update: Renamed "TP/SL" to "Auto close" throughout the UI

   • Order view: "Auto close" label
   • All user-facing strings updated
   • Technical abbreviations "TP" and "SL" retained for compact displays

3. UX Improvements:

   • Centered header title with absolute positioned back button
   • "Clear" action buttons positioned on same row as section titles (right-aligned)
   • Dollar symbol ($) positioned on LEFT of input fields (matching currency convention)
   • Removed explainer text at top of view
   • Percentage buttons no longer stay selected after press (cleaner UI)
   • Auto-scroll to keep inputs visible when custom keypad is active
   • Action buttons: "Cancel" + "Set" when keypad inactive, "Done" when keypad active

4. Implementation Approach (DRY):

   • Reuses existing calculatePnL() utility from pnlCalculations.ts
   • Reuses existing usePerpsOrderFees() hook for accurate fee calculation
   • Reuses existing calculatePositionSize() for new orders
   • Adds small calculateExpectedPnL() wrapper that combines P&L with fee deduction
   • Extends usePerpsTPSLForm hook return values (no new hooks created)
   • Reuses existing formatting utilities (formatPerpsFiat)
   • Uses custom Keypad component (no native keyboard, no timeout needed)

Changelog

CHANGELOG entry: Added expected profit/loss display to Auto Close (TP/SL) configuration showing net profit after fees, improved UI layout and terminology

Related issues

• Fixes: TAT-1729 https://consensyssoftware.atlassian.net/browse/TAT-1729
• Depends on refactor(perps): migrate tpsl bottomsheet to fullscreen view #21344

Manual testing steps

Feature: Expected Profit/Loss Display for Auto Close (TP/SL)

  Scenario: User sets Take Profit for new long position
    Given user is on the Order View screen for BTC
    And user enters an order amount of $100 at 2x leverage
    When user taps "Auto close"
    And user sets Take Profit to $105,000 (assuming current price is $100,000)
    Then user sees "Expected profit: $X.XX" below the TP input (right-aligned, BodyMD, Alternative color)
    And the amount accounts for closing fees

  Scenario: User sets Stop Loss for new short position
    Given user is on the Order View screen for ETH
    And user enters a short order amount of $50 at 3x leverage
    When user taps "Auto close"
    And user sets Stop Loss to $3,200 (assuming current price is $3,000)
    Then user sees "Expected loss: $X.XX" below the SL input (right-aligned, BodyMD, Alternative color)
    And the amount accounts for closing fees

  Scenario: User modifies TP/SL for existing position
    Given user has an existing long position in BTC
    And user taps "Edit TP/SL" from position card
    When user sets Take Profit to $110,000
    And user sets Stop Loss to $95,000
    Then user sees expected profit below TP input
    And user sees expected loss below SL input
    And both values are calculated from actual position entry price

  Scenario: Edge case - TP creates loss on modified position
    Given user has a long position with entry price $100,000
    And current price has moved down to $95,000
    When user sets Take Profit at $98,000 (still below entry)
    Then user sees "Expected loss: $X.XX" (smaller loss than current)
    And text is displayed in Alternative color (not Error color)

  Scenario: Verify UI improvements
    Given user is viewing the Auto Close screen
    Then user sees centered "Auto close" title with back button on left
    And "Clear" buttons appear on same row as "Take Profit" and "Stop Loss" titles (right-aligned)
    And dollar symbol "$" appears on LEFT of price input fields
    And percentage buttons do not stay selected after press
    And no explainer text appears at top of screen

  Scenario: Verify action buttons behavior
    Given user is on the Auto Close screen
    When keypad is NOT active
    Then user sees "Cancel" button (left) and "Set" button (right)
    When user taps any price or percentage input
    Then keypad appears and user sees only "Done" button
    When user taps "Done"
    Then keypad dismisses and user sees "Cancel" and "Set" buttons again

  Scenario: Verify auto-scroll for custom keypad
    Given user is on the Auto Close screen
    When user taps Take Profit price input
    Then view scrolls to offset 150px to keep input visible
    When user taps Stop Loss price input
    Then view scrolls to offset 350px to keep input visible
    And user can still manually scroll to see current price info

Screenshots/Recordings

Before

After

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I've included tests if applicable
• I've documented my code using JSDoc format if applicable
• I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.